Object-oriented and object-based programming techniques encapsulate computer programs and data in objects which separate implementation details from the contractual interface through which the objects are used. An object's interface defines the object's type, and is the view of the object exposed and accessible from outside the object. The interface is a usually a, listing of the operations and attributes that an operation provides. For example a, typical object interface includes the object's methods and their signatures together with any externally accessible fields. The details of the object's implementation other than those reflected in the interface are hidden. See Booch, Object-Oriented Analysis and Design, Addison-Wesley (1994). Objects are invoked through their interface.
Because an object invocation must conform to the object's interface, any entity seeking to invoke an object must have access to interface definition information for the object at the time it makes the invocation.
Interface information may be acquired either statically or dynamically. Statically acquired interface information is typically compiled or built into an invoking entity (usually another object), and cannot be changed without recompiling or modifying that entity. Dynamically acquired interface information, on the other hand, is typically acquired at run-time, and permits the construction of an invocation of an object having an interface that was unknown to the invoking entity prior to run-time.
Interface definition information may be acquired dynamically by interrogating objects for interface information about themselves, as for example through the Java introspection mechanism, or by acquiring the interface information from some other object or program as in the case of the CORBA Interface Repository.
Object interfaces are specified in a variety of ways. In an object-oriented language, an interface may be defined concretely by simply implementing it in an object. Alternatively, the interface may be specified apart from any object or class implementing the interface. Some object-oriented languages, such as Java, include an interface declaration keyword for abstractly defining interfaces. Abstract or virtual classes can also be used for this purpose in some languages.
A higher degree of abstraction and implementation independence may be achieved by defining interfaces in a language-independent interface definition notation. An interface defined this way may typically be implemented in more than one language, and objects so implemented in one language may typically invoke services of objects implemented in another language. In a distributed object-oriented environment, the ability to connect objects implemented in a variety of languages is a significant benefit.
One distributed object-oriented environment with multiple-language support is the Common Object Request Broker Architecture (“CORBA”) specification published by the Object Management Group. CORBA interfaces are defined abstractly using the CORBA Interface Definition Language (“CORBA IDL”), a declarative notation for defining interfaces. CORBA IDL is the means by which clients learn what operations are available from an object, and how they should be invoked.
The CORBA specification includes language mappings by which an interface defined in CORBA IDL is translated into “stub” code implementing the interface for an invoking object, and “skeleton” code implementing the interface on the invoked object. CORBA IDL language mappings exist for a variety of languages including Smalltalk, C++ and Java. See The Common Object Request Broker: Architecture and Specification, Revision 2.0, July 1995, updated July 1996.
Another distributed object-oriented environment supporting language-independent object definitions is included in the Open System Interconnection (OSI) network management standards published by the International Organization for Standardization (ISO). The Common Management Information Protocol (CMIP) and the Common Management Information Service Element (CMISE) defined in these standards incorporate a distributed object model for network management. This model is described in part in CCITT Recommendation X.722 (1992), “Information Technology—Open Systems Interconnection—Management Information Services—Structure of Management Information: Guidelines for the Definition of Managed Objects.” Objects defined in accordance with Recommendation X.722 are referred to in this specification as “GDMO objects.”
In the OSI world, objects are specified in GDMO/ASN.1. “ASN.1” refers to Abstract Syntax Notation One, a complex type definition notation. GDMO/ASN.1 object definitions are based on a set of templates used to describe managed objects used for network management and control. Among other object information, ASN.1 is used to define transfer syntaxes which can be used to invoke GDMO objects. ASN.1 is specified in ITU-T Recommendation X.208, “Specification of Abstract Syntax Notation One (ASN.1.)”.
When objects defined in one scheme (such as CORBA, for example) are used to manipulate (for example to invoke or instantiate) objects defined in another scheme (such as GDMO/ASN.1, for example), object definition information, including interface information must be somehow acquired across definition schemes.
Object definition information may be acquired across definition schemes by translating definitions from one scheme into the other. However, a syntactic or semantic mismatch between the schemes may make the translation or its results cumbersome or unworkable.
GDMO/ASN.1, for example, supports a richer variety of types than does CORBA IDL. Translation into CORBA IDL from ASN.1 often leads to unmanageable CORBA IDL definitions, and very large executables. Also, CORBA IDL translated from GDMO/ASN.1 is typically incomplete because information is lost during the translation process. The resulting collection of managed object definition information may not contain all the required information to perform CMISE operations.
There is therefore a need to provide a system for permitting objects having definitions in one definition notation to access object definitions specified in a different object definition notation in a manner that does not cause information to be lost in the process.
Accordingly, it is one objective of the present invention is to provide a first set of object definition information specified in a first notation to objects specified at least in part in a second notation without translating the first object definition information into the second object definition notation.
Another objective of the invention is to provide a means by which objects specified at least in part in a first object definition notation can invoke objects specified at least in part in a second object definition notation.
A further objective of the invention is to provide a means by which objects can instantiate objects defined at least in part in a foreign object definition notation.
Another objective of this invention is to provide a metadata repository by which a objects can use interfaces defined in a first object definition notation to discover object definitions specified in a second object definition notation.